A software program may be formed of a number of modules. For example, a software program that handles contact information of clients of a business may include the following modules: a mail tool, an address book and a calendar. Such modules may be produced separate from one another, individually tested, and then compiled and linked together to produce a single software program (also called “executable image”).
Software manufacturers often produce such a software program by modifying a prior version of the software program. To identify a current version from a prior version, such software programs are commonly given a name and a version number, e.g. Oracle 9i. Versions of individual modules of such a software program may be internally tracked by the software manufacturer using a version control system such as ClearCase by Rational Software of Lexington, Mass. (see www.rational.com).
A given version of software may be made available to users using a software release manager as described in an article entitled “Software Release Management” by Andr'e van der Hoek, Richard S. Hall, Dennis Heimbigner, and Alexander L. Wolf, Proceedings of the 6th European Software Engineering Conference, LNCS 1301, Springer, Berlin, 1997, which is incorporated by reference herein in its entirety.
Another article entitled “Software Release Management” available at www.cs.colorado.edu/serl/cm/SRM-long.html (which is also incorporated herein by reference in its entirety) describes an interface for a software release manager (abbreviated as SRM) to which a developer supplies information, such as the program name, the release number, release date, etc. In addition, the developer supplies the name of an archive file where the release is stored. After software has been released to SRM, it can be retrieved by a consumer using another part of SRM.
SRM allows a consumer to gain insight using a dependence-graph which can be obtained via a “Show Dependency Graph” button. For example, one may see that a release 2.0 of ProDag depends on release 3.1 of LPT, release 3.3 of Q, and release 2.0 of TAOS. However, these three dependencies were indicated by the developer, namely that ProDAG depends on release 3.1 of LPT, release 3.3 of Q, and release 2.0 of TAOS. In addition, one may see that ProDAG transitively depends on release 403.2 of Arpc, since release 3.3 of Q depends on that.